home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1340 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.9 KB
  1. Subject: Re: Just a couple of things. 
  2. Date: Thu, 28 Apr 94 23:37:36 +0200
  3. From: Erling Henanger <erlingh@idt.unit.no>
  4.  
  5. > 
  6. > In <9404271422.AA20250@hpbeo79.bbn.hp.com> you wrote :
  7. > 
  8. > >> Well, at least with source code to the CBHD driver, we would be able
  9. > >> to make such a driver. Making the driver respond to interrupts instead
  10. > >> of polling can't be that big a problem. At least not when all the
  11. > >> scsi setup code can be ripped off this driver. How much work it will
  12. > >> be to setup the queues of processes wanting to do IO under MiNT 
  13. > >> I won't comment on.
  14. > >
  15. > >It's certainly not trivial to get all debugged, but it's not the
  16. > >biggest issue. We need kernel reentrancy first, that's the main
  17. > >problem.
  18. > 
  19. > Bingo!
  20. > 
  21. > While we are talking about all this, and people are writing lots of code
  22. > to talk to the SCSI port(s)...
  23.  
  24. Exactly, this was one of the things I thought about.
  25. Just take this guy using a CD-rom. He will probably have:
  26.  
  27.     a) AHDI:         To control his hard-disks
  28.     b) MetaDOS or some .xfs: To control his CD-roms
  29.     c) Some kind of CD-audio player.
  30.  
  31. Now all of these programs/drivers contains code that are talking to
  32. the SCSI ports. And they might even be talking in each others mouth.
  33. Take AHDI for instance, it never *checks* the DMA-controller 
  34. semaphore - it just sets it and then goes on doing its thing.
  35. If,say, the audio-player was in the middle of performing some
  36. scsi-command when AHDI decided to do its thing, wild things could happen !
  37.  
  38. Some kind of /dev/scsi device that could actually send the commands
  39. for all of these programs would be very nice. Then, when the time
  40. comes and mint is reentrant, one would only have to rewrite the
  41. /dev/scsi driver to be interrupt driven, and all the high level
  42. stuff would instantly take advantage of it.
  43.  
  44. > 
  45. > Can we _please_ have a low-level SCSI driver that knows _nothing_ about 
  46. > filesystems or disks or anything like that?
  47.  
  48. Me too.
  49.  
  50. Erling
  51.